Background: The app embeds an in-app game feature ("Game Hub" / Fallinmoji) that is written in Java against libGDX and cross-compiled to native code for iOS using RoboVM (via ./gradlew :ios:robovmInstall). The build produces BWIOSGdx.xcframework, which is linked and embedded into the main iOS target. What we confirmed in the framework itself: The .xcframework does contain two genuinely separate Mach-O slices — one tagged LC_BUILD_VERSION platform=IOS (device) and one tagged platform=IOS SIMULATOR (arm64 simulator), so at the packaging level Xcode sees a proper simulator slice. Despite that, the framework does not run correctly under the Simulator, so our build script deliberately skips building/linking it entirely for iphonesimulator runs ("libGDX is device-only") and the feature is device-only in practice. Root cause (working theory): RoboVM AOT-compiles JVM bytecode into native ARM64 machine code and relies on hand-written runtime scaffolding (trampolines, dynamic method dispatch, JIT-adjacent code generation) that predates Apple Silicon simulators. That scaffolding appears to assume the calling conventions/execution environment of a physical device and does not behave correctly when executed inside the Simulator's process (which runs under different memory-protection/JIT and code-signing rules than a device). The result is that even though a correctly-tagged simulator slice exists, code compiled by RoboVM's toolchain does not execute reliably there — RoboVM itself has been effectively unmaintained since ~2017 and was never updated for Apple's current arm64 Simulator runtime. Impact: We cannot build/run/debug the Game Hub feature (and by extension, sometimes the whole app when this framework is force-included) in the Simulator, which blocks fast local iteration, CI-based UI testing, and any workflow that depends on Simulator rather than a provisioned physical device. Ask for Apple: Is this a known/expected limitation of running JIT-adjacent or non-Apple-toolchain-compiled native code (e.g., from RoboVM or similar Java→native cross-compilers) inside the iOS Simulator on Apple Silicon, versus on a physical device? Is there a supported mechanism (entitlement, code-signing flag, JIT-related capability) that would let such a framework execute correctly under Simulator, or is Simulator execution of dynamically-generated/trampoline-based native code from third-party toolchains fundamentally unsupported?

We have worked on the app for 3 years and have experience launching a similar app where we have users of the older version are asking for the new app in the App Store. We have many active TestFlight users asking for the App Store version. what can we do to get the app into the store?